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Date: 28 Feb 94 06:25:08 GMT
From: nprdc!ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!agate!library.ucla.edu!csulb.edu!tern.csulb.edu!usenet@network.ucsd.edu
Subject: Errors in TNC2 firmware???
To: ham-digital@ucsd.edu

  I have recently been experimenting with TNC2 clones and had run
across two peculiar "bugs" in the firmware of an MFJ 1278, and
a tiny TNC2.  
  
  The first problem relates to when the TNC2 sends to the computer
the "Change incoming stream" command ("|B" to switch to stream B, 
for example).  It seems that when in command mode, the TNC set the 
output stream to be equal to the input stream whenever it sends
the "cmd:" prompt (if, of course. the output stream was set to
something else previously).  So it you are in command mode in stream
A, and send a "|b" to set the input stream to B, and press Enter,
the tnc will respond with "|Bcmd:" to tell that the output stream
should now ALSO be set to stream B.  The problem is this:  The stream
switch is sent JUST before sending the cmd: prompt.  So if you are on
stream A in command mode, and type "|bcst<CR>" to set the input to
stream B and get the status of all streams, the tnc will send the
results, THEN the |B, then the new cmd: prompt.  SO, the output of
the cst  request made on stream B will be sent to stream A.  In fact,
the results will show that the input stream is B, while the output
stream is A!  Of course, if you type another "cst<CR>", the results
will be sent to the proper stream, because it has already been
corrected.  Do all TNC2's exhibit this feature?
 
The second problem is more major.  I seems that when I am connected
on two streams, and send text out on the first stream, and then
switch to the second and do nothing, all output from the tnc is
halted.  For example, if I am connected on stream A and B to two
bbs's, and I am currently on stream A, and I send "l<CR>|B" to list
all files on the first bbs and then switch my input to the second
bbs, the tnc will halt all output back to me.  The results of the
list command will come back to the tnc, and the tnc will receive them
all internally, but will not send them to the computer....UNTIL I
sent something to the tnc first.  (Usually I send "^ck<CR>" to enter
and then leave command mode.  This will then allow all buffered data
to be sent to me.  However, it you do not send anything to the tnc,
it will send nothing to you.
 
I have found these problems by using paKet 5.1.  PaKet creates
a different window for each of the tnc's streams, and pressing a 
shifted arrow key allows you to switch between the streams.  When you
do this, paKet sends a "|" and the stream identifier.  Therefore, it
is very easy to switch to another stream to view incoming data,
without wanting to send anything, thus causing the second problem.  
And having entering a command in one window and having the output
return in another window (the first problem)  was also easily
spotted.  I have reproduced these problems using a simple terminal,
so they are not errors with paKet.
 
One other note.  I have also played with some Kantronics Tnc.  They
do not appear to have the lockup problem, but have an even worse
version of the first bug.  The incoming stream sent from the Kan TNC's
is only changed when data comes in from over the air, not from
commands.  So if I am on stream A, and switch to stream B, SEND a
<CR>, (this would fix the TNC2 problem), and start sending commands,
the tnc never send me the stream switch command, so all the feedback
from my commands always goes to stream A, (or whatever the last
stream to receive over the air was).  This is very frustrating when
using paKet!
 
Anyone have any comments on any of this?  Has anyone else experienced
this?  Any ideas for solutions?  
 

-- 
Byon Garrabrant  KD6BCH  byon@csulb.edu

------------------------------

Date: 4 Mar 94 10:25:24 GMT
From: news-mail-gateway@ucsd.edu
Subject: IM_Mac1.0b27y.sea.hqx.text
To: ham-digital@ucsd.edu

=20
Release Notes - IM/Mac 1.0=A727y

- The numbers in the option-about dialog are now correctly formatted =
for all
  languages.

- Beachball cursor stops spinning immediately after finishing updatin=
g mail file
  when quitting.

- Beachball cursor stops spinning when a system error occurs.

- When a system error occurs, the dialog that shows has a 'MacsBug' b=
utton when
  MacsBug is running. This will create a file called 'crash_log' whic=
h you need
  to send me.

- Files with filetype 'ZSYS' and creator 'MACS' (e.g., 'VM Storage') =
can no
  longer be send. They're treated as invisible files like the Finder =
does.

- When selecting a file to send, the text inside the outlined button =
was 'Send'
  instead of 'Open' if the target was an alias to a folder.

- When the last item (Record) in the "Edit 'bm.rc'=C9" dialog contain=
ed only a
  filename, a system error occured. The syntax for that line is as fo=
llows:
[[[:<volume>:]<folder>:]<file>]. Square brackets enclose optional ite=
ms.

Examples:
:My Hard Disk:My TCP/IP Folder:spool:Archive:Sent Mail
spool:archive:sent mail
archive

- Finding out if MacsBug is installed via Gestalt doesn't work. Used =
another
  method.

- Sending a file that needs to be BinHex encoded will have its name t=
runcated to
  27 characters to make room for the '.HQX' suffix in the subject tit=
le. The
  original file name will reappear after the BinHex decoding takes pl=
ace at the
  receiver's end.

- Deleted mail icon was 1 pixel too high.

- Does stuff/unstuff of files on system 7 Macintoshes that have 'Stuf=
fIt
  Engine=AA' (version 3.0 and higher) in the Extensions folder. Files=
 that were
  compressed/made with StuffIt, Compact Pro, AppleLink, DiskDoubler o=
r
  UpdateMaker won't stuff twice.

- Beachball cursor kept spinning when a system error occured during B=
inHex
  encoding.

- On popular demand:

AX25 mail: on1xk@on6ar.#an.bel.eu
AMPRnet:   ivo@on1xk [44.144.8.5]
Internet:  on1xk@gg.tno.nl
AppleLink: vanursel.ivo

Monday, February 28, 1994 - 18:48:54 UTC

Best 73's, es cuagn de Ivo, ON1XK @ ON6AR.#AN.BEL.EU [44.144.8.5]
Wednesday, March 02, 1994 - 19:55:15 +0000 UTC


PS (by PA2AGA)

This version obsoletes all versions of info-mac/comm/radio-immac in t=
he
Sumex-Aim archives.

The new IM/Mac has (hopefully) been uploaded to ftp.std.com, to the
directory pub/hamradio/incoming, and to ucsd.edu, to the directory
/hamradio/packet/tcpip/incoming. If it's not there (anymore),
then look at /hamradio/packet/tcpip/mac.

------------------------------

End of Ham-Digital Digest V94 #58
******************************
******************************
